The radio-based communication networks of today are generally good enough for supporting video streaming, at least with regard to devices with small screens, such as smart phones. For instance, the resolution of the retina screen in iPhone 5S is 1136×640 pixels, which can be supported in terms of video streaming over a Long Term Evolution (LTE) network.
While current solutions may work well for linear play out or playback, the same is not true for video navigation, i.e. when the user moves the video cursor to another part of the streamed video bitstream. As an example, if the user wants to jump twenty minutes ahead in a Netflix movie, the video data at this position is not available at the user's video player. The video player must first request the video data at this position from the Netflix movie server. However, even after receiving the first few frames or pictures at this position, the play out of video data is still not started. The reason for this is that a video player typically needs to build up a buffer of video data before starting to play out the video. This buffering of video data is needed since the network bandwidth can be choppy and suddenly drop. The video player then wants to build up a sufficiently large buffer before starting the play out to be sure not to deplete the buffer if the bit rate would suddenly drop, which would cause the video player to freeze the video play out.
Video navigation backwards in time, i.e. to a previous, already played out position within the streamed video bitstream, generally denoted rewinding in the art, does not work well with current technology. For some video applications, such as Netflix running on Playstation 3 (PS3), rewinding is possible to a position 30 s backwards in time by pushing the “left” button on the remote control once. Pushing the “left” button twice triggers rewinding to a position 1 min backwards in time. However, if the “left” button is pushed more than twice to jump even further backwards in the already played out part of the streamed video bitstream then a same request and buffering procedure takes place as when jumping ahead in time. This means that there will be a significant delay from jumping back in time by pressing the “left” button until the play out is resumed.
Thus, there is a need for an efficient solution of tuning into a streamed video bitstream, such as during video navigation when the user moves to a previous, already played out part of the streamed video bitstream. It is particularly a need for such a solution that reduces the delay before the video play out is resumed following video navigation.